Operational environments exist in many forms and cover a wide variety of equipment, from something as simple as thermostats controlling a room's temperature, to a command and control center running a complex industrial installation such as an oil refinery, or a sophisticated mission such as flying an unmanned aerial vehicle. Despite this wide variation, an operational environment usually uses a collection of control devices, including for example a Programmable Logic Controller (PLC), to monitor the status and conditions of many of the systems (and subsystems) and other devices under its control, as well as to modify the behavior and/or the monitoring modalities of the device (e.g., PLC). Remote monitoring and behavior changes can be accomplished by reading from and writing to specific memory locations (registers) in the control device, respectively, using for example a Modbus protocol in a Supervisory Control and Data Acquisition (SCADA) system. Also, the monitored values may be used by the control device to independently modify the behavior of the equipment under its control, using a previously stored program in local memory. For the purpose of this disclosure, the modification of a stored program on a control device is considered equivalent to the writing a set of commands to specific memory locations on the same device.
In most cases, either because the control device was designed to operate in a protected environment or because the security risks were deemed negligible, there is little or no built-in protection when the apparatus is connected to a network or is otherwise accessible in a non-controlled fashion, either to accept commands or to output status information. Most current solutions for securing an existing control device use physical isolation or software-based firewalls to protect the network connected to the apparatus. As a result, it is possible to compromise the control device via a network or other external connection (termed herein “Network Risk”), to effectively subvert the control device operation, for example, by allowing malware to be introduced which issues commands that change the operational parameters of the controlled equipment or otherwise render the equipment unusable, while optionally giving out erroneous status readings to hide such actions.
Assuming the Network Risk is somehow mitigated, there is still an additional security exposure if physical access is gained to the operational environment, as would be the case if an individual is able to enter a control room or connect to an internal network linked to the control device. Examples of such exposures include the subversion or impersonation of legitimate employees, as well as physical break-ins (termed herein as “Insider Risk”). Insider Risk relies on the lack of further safeguards, once the access or connection is accomplished, to protect the control device from accepting commands to subvert its operation or exfiltrate information from associated control equipment. Properly addressing the Network Risk will result in the secure delivery of commands from an authorized source, while properly dealing with Insider Risk will ensure that the authorized source has not been compromised and will only issue valid commands.
User IDs and associated passwords are common methods for addressing the Insider Risk in computing systems and are also routinely used in operational environments. In some cases, these methods are augmented by the use of biometric features, such as voice or fingerprint. A known weakness of these methods is that there is no practical limitation to what can be done once access to a system is obtained. Role-Based Access Control (RBAC) methods address this weakness by restricting access to information and ability to perform operations to a subset of the resources in a system, depending on the particular role or roles an individual has in an organization. RBAC methods provide an additional layer of protection for the various assets and components of an operational environment, even when these are located in the same physical space as no-operational systems or share computational resources with them. Furthermore, RBAC methods simplify the process of changing access permissions as a person changes roles within an organization, as the permissions are linked to a role and not a person.
The Network Risk and/or the Insider Risk may be deemed unacceptable for certain environments because the result of either operational failure or information leakage have intolerable consequences.
Alternative network security methods and devices based on unidirectional data transfer have been devised to address the network security concern. For example, U.S. Pat. No. 5,703,562 to Nilsen (“the '562 patent”), the contents of which are hereby incorporated by reference in its entirety, provides an alternative way to address the network security concern. The '562 patent discloses a method of transferring data from an unsecured computer to a secured computer over a one-way optical data link comprising an optical transmitter on the sending side and an optical receiver on the receiving side. By providing such an inherently unidirectional data link to a computer/data network to be protected, one can eliminate any possibility of unintended data leakage out of the computer/data network over the same link.
Any data link that strictly enforces the unidirectionality of data flow is called a one-way link or one-way data link. In other words, it is physically impossible to send information or data of any kind through a one-way data link in the reverse direction. A one-way data link may be hardware-based, software-based, or based on some combination of hardware and software.
One-way data transfer systems based on such one-way data links provide network security to data networks by isolating the networks from potential security breaches (i.e., undesired and unauthorized data flow out of the secure network) while still allowing them to import data from the external source in a controlled fashion. FIG. 1 schematically illustrates an example of one such one-way data transfer system 100. In the one-way data transfer system shown in FIG. 1, two computing platforms 101 and 102 (respectively, “the send platform” and “the receive platform”) are connected to the unsecured external network 104 (“the source network”) and the secure network 105 (“the destination network”), respectively. The send platform 101 is connected to the receive platform 102 by a one-way data link 103, which may be an optical link comprising, for example, a high-bandwidth optical fiber. This one-way optical data link 103 may be configured to operate as a unidirectional data gateway from the source network 104 to the secure destination network 105 by having its ends connected to an optical transmitter on the send platform and to an optical receiver on the receive platform.
A configuration such as the one shown in FIG. 1 physically enforces one-way data transfer at both ends of the optical fiber connecting the send platform 101 to the receive platform 102, thereby creating a truly unidirectional data transfer link between the source network 104 and the destination network 105. One-way data transfer systems based on a one-way data link are designed to transfer data or information in only one direction, making it physically impossible to transfer any kind of data, such as handshaking protocols, error messages, or busy signals, in the reverse direction. Such physically imposed unidirectionality in data flow cannot be hacked by a programmer, as is often done with firewalls, where unidirectional rules are software-protected (e.g., password authentication, etc.). Accordingly, the one-way data transfer system based on a one-way data link ensures that data residing on the isolated destination secure computer or network is maximally protected from any undesired and unauthorized disclosure. Alternatively, the source network is isolated from any malware contained in the destination network.
As described in U.S. Pat. No. 8,352,450, issued on Jan. 8, 2013, the contents of which are incorporated herein by reference, files based on various conventional transport protocols may be transferred across a one-way data link under suitable arrangements. The following example illustrates transfer of files based on the Transmission Control Protocol (TCP) across a one-way data link. FIG. 2 is a functional block diagram that schematically illustrates implementation of a TCP-based secure file transfer across a single one-way data link in a one-way data transfer system 200.
Construction of the conventional TCP sockets requires bilateral communications since it requires an acknowledgement channel from the receive node to the send node. Accordingly, the conventional TCP/IP protocol cannot be implemented directly in a one-way data transfer system based on a one-way data link, since no bilateral “hand shaking” is allowed over the one-way link due to physical enforcement of unidirectionality of data flow. Instead, the one-way data transfer system 200 illustrated in FIG. 2 uses a TCP simulation application called TCP proxy, which is preferably a TCP/IP socket-based proxy software, but may also be hardware-based or based on a suitable combination of software and hardware, to simulate the TCP/IP protocol across the one-way data link 207.
In FIG. 2, a TCP server proxy 205 fully implements the TCP/IP protocol in its bilateral communications 203 with the upstream TCP file client 202 residing in a source platform 201. The TCP server proxy 205 may reside within the send node 204 as shown in FIG. 2, or alternatively, may be separate from but coupled to the send node 204. After the TCP server proxy 205 receives files from the TCP file client 202, the send node 204 sends the files through its interface 206 to the one-way data link 207. After the receive node 208 receives the files through its interface 209 from the one-way data link 207, the TCP client proxy 210 communicates under the full implementation of the TCP/IP protocol with a TCP file server 213 residing in a destination platform 212 and forwards the received files to the TCP file server 213. The TCP client proxy 210 may reside within the receive node 208 as shown in FIG. 2, or alternatively, may be separate from but coupled to the receive node 208.
In certain situations, it would be advantageous to use a one-way data link with an independent link layer protocol for one-way transfer so that non-routable point to point communications with a true IP protocol break can be enforced. With these properties, data packets or files cannot be accidentally routed in the network and other protocols (such as printer protocols, etc.) will not route across the one-way data link. An exemplary configuration enforcing such non-routable point to point communications with a true IP protocol break can be implemented in the one-way file transfer system 200 of FIG. 2. The TCP-based file transfer system 200 may be configured to prohibit transmission of IP information across the one-way data link 207. When the TCP server proxy 205 receives a file from the TCP file client 202, it removes the IP information normally carried in the file data packet headers under the TCP/IP protocol and replaces it with pre-assigned point-to-point channel numbers, so that no IP information is sent across the one-way data link 207. Instead, predetermined IP routes may be defined at the time of the configuration of the system 200 in the form of channel mapping tables residing in the TCP server proxy 205 associated with the send node 204 and the TCP client proxy 210 associated with the receive node 208. The send node 204 then sends the files with the pre-assigned channel numbers to the receive node 208 through its interface 206 across the one-way data link 207, which are received by the receive node 208 through its interface 209. Upon receipt of the files, the TCP client proxy 210 then maps the channel numbers from the received files to the corresponding predetermined IP address of a destination platform 212, to which the files are forwarded.
For the security of the overall one-way file transfer system 200, the IP address-to-channel number mapping table residing in the send node 204 may be different from the channel number-to-IP addressing mapping table residing in the receive node 208, and furthermore, neither table may be re-constructed on the basis of the other table. Neither table alone reveals the overall IP routing configuration from the source platform 201 to the destination platform 212. In this way, the IP information of the destination platform 212 may remain undisclosed to the sender at the source platform 201 and the security of the overall system 200 can be maintained.
Under the conventional TCP/IP protocol, the acknowledgement mechanism requiring bilateral communications may provide means for error detection. However, the one-way data link 207 forecloses such means. Instead, the one-way data transfer system 200 may assure file integrity by applying, for example, a hash algorithm such as MD5 to each file being transferred over the one-way data link 207. The send node 204 calculates an MD5 hash number for the file and sends the resulting hash number along with the file to the receive node 208 over the one-way data link 207. When the receive node 208 receives the file, it may re-calculate a hash number for the received file and compare the result with the hash number calculated by the send node 204. By comparing these results, the receive node 208 may be able to determine as to whether any error has occurred during the file transfer across the one-way data link.
It is an object of the present invention to provide a secure method for sending commands or programs to be executed by a control apparatus, such as a PLC or similar computing device, to monitor the status and/or modify the behavior of industrial and other equipment.
Other objects and advantages of the present invention will become apparent from the following description.